Secure client authentication based on conditional provisioning of code signature

ABSTRACT

A memory subsystem includes a memory interface for accessing a non-volatile memory (NVM), a host interface for communicating with a host, and a processor. The processor is configured to calculate a signature over program code that is used by the host and is stored in the NVM, to verify, upon detecting a boot process performed by the host, whether the boot process is legitimate, and, only if the boot process was verified to be legitimate, to provide the signature to the host for authentication to a remote server.

FIELD OF THE INVENTION

The present invention relates generally to secure communication and datastorage, and particularly to methods and systems for authentication ofsecure client devices.

BACKGROUND OF THE INVENTION

A secure client communicating with a server is sometimes required toauthenticate itself to the server, and to prove that it has not beencompromised by a hostile third party. Various solutions have beenproposed for this sort of authentication process. Some solutions involvecreating and reporting to the server a secure identity of the client.For example, the Trusted Computing Group (TCG) specifies a solutioncalled “Device Identifier Composition Engine” (DICE), in “TrustedPlatform Architecture Hardware Requirements for a Device IdentifierComposition Engine,” Family 2.0, Level 00, Revision 69, Dec. 16, 2016,which is incorporated herein by reference.

SUMMARY OF THE INVENTION

An embodiment of the present invention that is described herein providesa memory subsystem including a memory interface for accessing anon-volatile memory (NVM), a host interface for communicating with ahost, and a processor. The processor is configured to calculate asignature over program code that is used by the host and is stored inthe NVM, to verify, upon detecting a boot process performed by the host,whether the boot process is legitimate, and, only if the boot processwas verified to be legitimate, to provide the signature to the host forauthentication to a remote server.

In some embodiments, the processor is configured to store the signaturein a volatile register, and to clear the volatile register in responseto detecting that the boot process is not legitimate. In someembodiments, the processor is configured to verify whether the bootprocess is legitimate by verifying whether one or more first accesses ofthe host to the NVM are addressed to a range of memory addressespredefined as legitimate. In an embodiment, when the boot process isverified to be legitimate, the processor is configured to modify therange of memory addresses predefined as legitimate.

There is additionally provided, in accordance with an embodiment of thepresent invention, a secure client device including a non-volatilememory (NVM), a host and a memory subsystem. The memory subsystem isconfigured to access the NVM for the host, to calculate a signature overprogram code that is used by the host and is stored in the NVM, toverify, upon detecting a boot process performed by the host, whether theboot process is legitimate, and, only if the boot process was verifiedto be legitimate, to provide the signature to the host forauthentication to a remote server.

There is further provided, in accordance with an embodiment of thepresent invention, a method including calculating a signature overprogram code that is used by a host and is stored in a non-volatilememory (NVM). Upon detecting a boot process performed by the host, averification is made whether the boot process is legitimate. Thesignature is provided to the host, for authentication to a remoteserver, only if the boot process was verified to be legitimate.

The present invention will be more fully understood from the followingdetailed description of the embodiments thereof, taken together with thedrawings in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that schematically illustrates a secure clientdevice communicating with a remote server, in accordance with anembodiment of the present invention; and

FIG. 2 is a flow chart that schematically illustrates a method forconditional provisioning of code signature, in accordance with anembodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS Overview

Embodiments of the present invention that are described herein provideimproved methods and systems for authentication of secure client devicesvis-à-vis remote servers. In the disclosed embodiments, a secure clientdevice comprises a Non-Volatile Memory (NVM), a host, and a memorysubsystem that accesses the NVM on behalf of the host. As part of anauthentication process between the secure client device and a server,the host is required to provide the server with a signature calculatedover some or all of the program code (software code) of the host, whichis stored in the NVM.

A possible security vulnerability of such a process is that a hostilethird party may gain access to the correct signature. The third partymay authenticate itself to the server using the correct signature, butthen communicate with the server using rogue program code. In someembodiments, the memory subsystem of the secure client device eliminatesthis and other vulnerabilities, by providing the signature to the hostonly upon verifying that the boot process of the secure client device islegitimate.

In an example embodiment, the memory subsystem calculates the signatureover the program code, and stores the signature in a volatile register.This preparatory step can be performed at any suitable time before thesecure client device boots. At a later point in time, the memorysubsystem detects the beginning of the boot process of the secure clientdevice. For example, the memory subsystem may detect the (one or more)first read commands issued from the host to the NVM. The memorysubsystem verifies whether the boot process is legitimate or not, e.g.,by checking whether the first read commands are addressed to memoryaddresses known to contain legitimate boot code. If the boot processappears to be illegitimate, the memory subsystem erases the content ofthe volatile register holding the signature.

When the memory subsystem operates in the above-described manner, only ahost that performs the legitimate boot process will be able to providethe correct signature to the server. A rogue host, characterized by anillegitimate boot process, will not receive the correct signature fromthe memory subsystem and will not be able to authenticate itself to theserver.

In some embodiments, once a legitimate code boots from the range ofaddresses that was predefined as legitimate, the code is permitted tomodify (e.g., expand) this address range. This feature allows legitimatecode to continue executing from a larger address range without causingerasure of the signature.

The disclosed techniques are typically implemented in hardware withinthe memory subsystem, and are transparent to the host. The techniquesdescribed herein are simple to implement, but at the same time provide ahigh degree of security. The disclosed techniques can be embedded invarious authentication frameworks, e.g., in the TCG DICE framework.

System Description

FIG. 1 is a block diagram that schematically illustrates a system 20 inwhich a secure client device 24 communicates with a remote server 28over a communication network 32, in accordance with an embodiment of thepresent invention. Secure client device 24 and remote server 28 arereferred to herein simply as “client” and “server” for brevity.

In one example embodiment, client 24 is part of an Internet-of-Things(IoT) terminal and server 28 comprises an IoT application server. Inanother example embodiment, client 24 is part of an automotive subsystemin a vehicle, and server 28 comprise a central computer of the vehicle.Further alternatively, client 24 and server 28 may comprise any othersuitable computing platforms used for any other suitable application.Network 32 may comprise any suitable communication network, e.g., aLocal-Area Network (LAN), a Wide-Area Network (WAN) such as theInternet, a cellular network, or a combination of two or more networks.

In the example of FIG. 1, client 24 comprises a host processor 36(referred to simply as “host”), a Non-Volatile Memory (NVM) 40 and amemory subsystem 44. Host 36 may comprise any suitable processor. In thepresent example, NVM 40 comprises a Flash memory, but any other suitabletype of NVM can be used in alternative embodiments. NVM 40 is used forstoring various kinds of data, including the program code (softwarecode) that host 36 runs. Memory subsystem 44 accesses NVM 40 on behalfof host 36. For example, memory subsystem 44 receives read and writecommands issued by host 36, and executes the commands in NVM 40.

In the embodiment of FIG. 1, memory subsystem 44 comprises a hostinterface 48 for communicating with host 36, a memory interface forcommunicating with NVM 40, and a processor 56 that is configured toperform the various tasks of the memory subsystem. Among other tasks,processor 56 calculates a secure signature over the program code storedin NVM 40 and stores the signature in a volatile register 60. Processor56 also identifies whenever host 36 begins its boot process from NVM 40,verifies whether the boot process is legitimate, and, if not, deletesthe content of register 60. This security mechanism is described indetail below.

The configurations of system 20 and client 24 shown in FIG. 1 areexample configurations that are depicted purely for the sake ofconceptual clarity. In alternative embodiments, any other suitableconfigurations can be used. In one embodiment, memory subsystem 44 andNVM 40 are fabricated in a single System-on-Chip (SoC), e.g., inrespective semiconductor dies packaged in the same device package. Inanother embodiment, memory subsystem 44 and NVM 40 are fabricated asseparate devices. Elements that are not mandatory for understanding ofthe disclosed techniques have been omitted from the figure for the sakeof clarity.

In various embodiments, the different elements of client 24 shown inFIG. 1 may be implemented using any suitable hardware, such as in anApplication-Specific Integrated Circuit (ASIC) or Field-ProgrammableGate Array (FPGA). Alternatively, some of the functions of client 24,e.g., the functions of host 36 and/or of processor 56, may beimplemented in software, or using a combination of software and hardwareelements.

Typically, host 36 and processor 56 comprise general-purpose processors,which are programmed in software to carry out the functions describedherein. The software may be downloaded to any of the processors inelectronic form, over a network, for example, or it may, alternativelyor additionally, be provided and/or stored on non-transitory tangiblemedia, such as magnetic, optical, or electronic memory.

Conditional Provisioning of Program-Code Signature by Memory Subsystem

In some embodiments, client 24 is required to authenticate itself toserver 28 and prove its security has not been compromised. In an exampleauthentication process, client 24 calculates a signature over at leastpart of the program code of host 36, as stored in NVM 40. Client 24 usesthe signature value for authenticating itself to the server. The servertypically compares the signature provided by the client with an expectedvalue of the signature. The client may calculate the signature, forexample, by applying a one-way cryptographic operation to the programcode. A typical example of a one-way cryptographic operation is ahashing function such as SHA.

In some embodiments, memory subsystem 44 carries out an additionalsecurity mechanism, which ensures that the signature is provided only tothe original code and not to any rogue code. In these embodiments,processor 56 of memory subsystem 44 saves the signature in volatileregister 60. Upon detecting that host 36 begins its boot process,processor 56 verifies whether the boot process is legitimate. Ifprocessor 56 suspects that the boot process is illegitimate (meaningthat host 36 is likely to have been compromised), the processor clearsthe content of register 60, thereby erasing the signature. As such, onlyprogram code that performs a legitimate boot process will be able toobtain (and authenticate to the server using) the true signature value.

FIG. 2 is a flow chart that schematically illustrates a method forconditional provisioning of the code signature, carried out by processor56 of memory subsystem 44, in accordance with an embodiment of thepresent invention. In the first stage of the method (steps 70-86),processor 56 calculates and saves the code signature. This stage can beperformed at any suitable time before client 24 is booted, for examplebefore every boot and/or following software upgrade. In the second stageof the method (step 90-102), processor 56 makes the signature availableonly to the legitimate program code.

The method begins with processor 56 loading an initialization vector(key) for calculating the code signature, at a key loading step 70. At adata readout step 74, processor 56 reads the next data chunk (e.g., wordor page) from the region of NVM 40 used for storing the program code ofhost 36.

At a hashing step 78, processor 56 hashes the data chunk. The hashingoperation is incremental, i.e., each iteration of step 78 provides acumulative signature of the recently-loaded data chunk and all previousdata chunks.

At a termination checking step 82, processor 56 checks whether all therequired program code (the code over which the signature is defined) hasbeen hashed. If not, the method loops back to step 74 above for readingthe next chunk of program code from NVM 40. After the entire programcode has been hashed, processor 56 saves the resulting signature involatile register 60, at a signature storage step 86.

At some later point in time, processor 56 detects that host 36 begins toperform a boot process, at a boot detection step 90. For example,processor 56 may detect the (one or more) first read commands issued byhost 36 to NVM 40 following power-up.

At a boot verification step 94, processor 56 checks whether the detectedboot process is legitimate or not. In one embodiment, processor 56 isaware of the memory addresses in which the genuine boot code of host 36is stored. Upon detecting the first read commands issued by host 36following power-up, processor 56 assumes that these read commands shouldbe addressed to these addresses.

If the first read commands are indeed addressed to the expected memoryaddresses, processor 56 concludes that the boot process is legitimate,and continues execution, at a normal execution step 98. In particular,if host 36 will subsequently request the code signature from memorysubsystem 40, processor 56 will return the true signature value storedin register 60.

If, on the other hand, the first read commands are not addressed to theexpected memory addresses, processor 56 concludes that the boot processhas been compromised by some hostile party. In response, processor 56clears the content of register 60, at a signature erasure step 102,before reverting to normal execution step 98. In such a case, host 36 isunable to retrieve the code signature. As a result, the illegitimatecode will not be able to complete the authentication process with server28.

The method flow of FIG. 2 is an example flow, which is depicted purelyfor the sake of conceptual clarity. Any other suitable flow can be usedfor implementing the disclosed techniques in alternative embodiments.For example, processor 56 may use other criteria for verifying whetherthe boot process of host 36 is legitimate or not, not necessarilyrelating to the memory addresses being read.

As another example, as noted above, once processor 56 completes alegitimate boot process, the processor may modify the range of addressesthat is considered legitimate for code readout. In this manner,processor 56 may continue executing legitimate code from a largeraddress range without causing erasure of the signature in register 60.

In some embodiments, at least the functions of processor 56 that verifythe boot process and clear register 60 are implemented using dedicatedhardware logic in the memory subsystem, making them difficult tocircumvent.

It will be appreciated that the embodiments described above are cited byway of example, and that the present invention is not limited to whathas been particularly shown and described hereinabove. Rather, the scopeof the present invention includes both combinations and sub-combinationsof the various features described hereinabove, as well as variations andmodifications thereof which would occur to persons skilled in the artupon reading the foregoing description and which are not disclosed inthe prior art. Documents incorporated by reference in the present patentapplication are to be considered an integral part of the applicationexcept that to the extent any terms are defined in these incorporateddocuments in a manner that conflicts with the definitions madeexplicitly or implicitly in the present specification, only thedefinitions in the present specification should be considered.

The invention claimed is:
 1. A memory subsystem, comprising: a memoryinterface for accessing a non-volatile memory (NVM); a host interfacefor communicating with a host; and a microprocessor, configured to:calculate a signature over program code that is used by the host and isstored in the NVM; upon detecting a power-up of the host, verify whetherfirst read commands issued by the host following the power-up aredirected to addresses in accordance with predefined addresses expectedfor a genuine boot code; and only if the first read commands wereverified to be directed to addresses of the genuine boot code, providethe signature to the host for authentication to a remote server.
 2. Thememory subsystem according to claim 1, wherein the processor isconfigured to store the signature in a volatile register, and to clearthe volatile register in response to detecting a read command addressedto an address outside a range of the genuine boot code.
 3. The memorysubsystem according to claim 1, wherein the processor is furtherconfigured to verify that memory accesses after the first read commandsissued by the host following the power-up are directed to a range ofmemory addresses considered legitimate for after boot access, whereinthe range of memory addresses considered legitimate for after bootaccess is larger than a range including the predefined addressesexpected for a genuine boot code.
 4. A secure client device, comprising:a non-volatile memory (NVM); a host; and a memory subsystem, configuredto: access the NVM for the host; calculate a signature over program codethat is used by the host and is stored in the NVM; upon detecting apower-up of the host, verify whether first read commands issued by thehost following the power-up are directed to addresses in accordance withpredefined addresses expected for a genuine boot code; and only if thefirst read commands were verified to be directed to addresses of thegenuine boot code, provide the signature to the host for authenticationto a remote server.
 5. The secure client device according to claim 4,wherein the memory subsystem is configured to store the signature in avolatile register, and to clear the volatile register in response todetecting a read command addressed to an address outside a range of thegenuine boot code.
 6. The secure client device according to claim 4,wherein the memory subsystem is further configured to verify that memoryaccesses after the first read commands issued by the host following thepower-up are directed to a range of memory addresses consideredlegitimate for after boot access, wherein the range of memory addressesconsidered legitimate for after boot access is larger than a rangeincluding the predefined addresses expected for a genuine boot code. 7.A method, comprising: calculating a signature over program code that isused by a host and is stored in a non-volatile memory (NVM); upondetecting a power-up of the host, verifying whether first read commandsissued by the host following the power-up are directed to addresses inaccordance with predefined addresses expected for a genuine boot code;and only if the first read commands were verified to be directed toaddresses of the genuine boot code, providing the signature to the hostfor authentication to a remote server.
 8. The method according to claim7, and comprising storing the signature in a volatile register, andclearing the volatile register in response to detecting a read commandaddressed to an address outside a range of the genuine boot code.
 9. Themethod according to claim 7, and comprising verifying that memoryaccesses after the first read commands issued by the host following thepower-up are directed to a range of memory addresses consideredlegitimate for after boot access, wherein the range of memory addressesconsidered legitimate for after boot access is larger than a rangeincluding the predefined addresses expected for a genuine boot code.